This invention relates generally to cache management. More particularly, the present invention relates to methods and systems for the optimization of system resources during cache management. Even more particularly, the present invention relates to a system and method for polling assets in a cache at different frequencies depending upon the relative activity of the assets.
A cache is essentially a buffer between a high-speed system and a low-speed system. Caches are becoming increasingly important for use in computers and computer systems in which there may be several devices running at different speeds. Even in a single computer, caches may be necessary to optimize performance. For example, in the common desktop personal computer (xe2x80x9cPCxe2x80x9d), there are typically many different layers or levels of cache. Level 1 or primary cache is the fastest cache in the PC and is typically built into the central processing unit (xe2x80x9cCPUxe2x80x9d) (level 1 cache is also called xe2x80x9cinternalxe2x80x9d cache as it is integrated directly with the CPU). Although this cache is generally very small (e.g., under 100 KB) it runs at or near the CPU speed. Level 1 cache is used to store the highest priority and most often accessed instructions. Because the most commonly used instructions are stored in Level 1 cache, that runs at or near the same speed as the CPU, they can be accessed quickly and easily by the CPU.
While it may be desirable to store all commonly used instructions in such a fast memory, such memory is prohibitively expensive. Therefore, other commonly used instructions can be stored in level 2 cache. Level 2 cache can typically store a greater number of instructions than level 1 cache (e.g., can store more than 1 MB) but is slightly slower. If an instruction cannot be found in the level one cache, the CPU will look for the instruction in the level 2 cache. In addition to storing instructions in level 1 and level 2 cache, commonly accessed instructions can also be stored in system RAM, which is slightly slower than level 1 or level 2 cache, but is significantly faster than a hard disk drive or floppy disk drive, where instructions would otherwise be stored.
By storing commonly accessed instructions in various levels of cache, a computer""s performance can be significantly increased. This is because during the execution of a program the same instructions are typically accessed repeatedly. By storing the most accessed instructions in the highest speed cache (e.g., level 1 cache) and so on, the CPU can access the instructions at the speed of the respective cache rather, than at the speed of, for example, a relatively slow disk drive. Thus, the use of various levels of cache can significantly enhance computer performance.
Caches are not only useful to buffer instructions between internal components of a computer, but can also be used to buffer files exchanged between systems that have different access speeds. For example, caching is a commonly employed tool for displaying web pages over the Internet. When a user accesses a web page via the Internet, the speed at which a page can be downloaded to his/her computer is typically dictated, not by processor speed or available system RAM, but instead by the speed of the connection between the user""s computer and the web server at which the web page resides. In order to increase the speed at which pages are downloaded, many Web browsers can cache commonly downloaded web pages or components of web pages. For example, the user""s Web browser could cache images from the web page that are repeatedly accessed, such as buttons or banners, on the user""s hard disk drive. When the user attempts to download the same web page or related web pages that use the same buttons and/or banners, the buttons or banners can be downloaded from the hard disk drive rather than from the Web server (i.e., over the much slower network connection), thereby significantly decreasing the download time.
Similarly, a cache can be used to increase the speed with which files on a database (xe2x80x9cdatabase assetsxe2x80x9d) can be accessed and modified. In current systems, when a user requests a database asset from a database, a copy of the database asset is sent to the user""s computer and can be cached on the user""s hard disk drive. When the user accesses or modifies the database asset, he/she, in some applications, accesses the cached file on the hard drive and not the database asset stored on the database. Again, because the file is accessed from the hard disk drive and not over a relatively slow network connection, the file can be accessed and modified much more quickly. When the user has completed work on the cached file, the cached filed can be reconciled or synchronized with the file on the database For example, in the manner described in related U.S. patent application Ser. No. 10/033,242, entitled xe2x80x9cSystem and Method for Synchronization of a File in a Cache,xe2x80x9d filed on Dec. 28, 2001 now pending, by inventors David Thomas and Scott Wells (the xe2x80x9cSynchronization Applicationxe2x80x9d) which is hereby fully incorporated by reference.
For file caches (e.g., caches that contain files rather than instructions), particularly for those associated with databases and/or the Internet, cache management presents several difficulties. One such difficulty is that if many files are cached, the memory that stores the cache can eventually become saturated (i.e., reach capacity). Therefore, a cache management program must be implemented to delete files from the cache. In current systems, the cache management program is typically integrated into the application or program that actually accesses files from the cache. Thus for example, a typical database synchronization program (e.g., a program that synchronizes cached files on a user""s computer with database assets in a database) or Internet browser will have a cache management aspect to manage the cache of database or Internet files on the user""s computer. In these systems, the cache management program generally maintains a list of cached files and periodically removes files from the cache. These systems, however, have significant shortcomings because the cache management portion of this software must be subsumed by another program. In order to manage the cache, the cache management program must receive detailed contextual information, such as when a particular file was last accessed or last modified from another portion of the same software program. Furthermore, synchronization programs are typically designed for use with only one application, limiting the usefulness of a cache management program associated with the synchronization program. Thus, the cache management portion can typically only manage files associated with the overall program of which the cache management program is a part.
Additionally, current cache management systems generally do not optimize system resources. Typically, the cache management system will review the list of cached files on a predetermined frequency. As the list of cached files grows, reviewing the list will take progressively longer. The current cache management systems, however, do not account for the fact that some files in the cache may be less active than others. Therefore, reviewing less active files can consume as many, if not more, system resources as reviewing active files.
The present invention provides a system and method for optimizing a cache that substantially eliminates or reduces the disadvantages of previously developed cache management systems. More particularly, embodiments of the present invention provide a method and system for optimizing a cache by polling cached assets with a frequency that can be dependent on the relative activity of the cached asset being polled. One embodiment of the method of the present invention includes the steps of: (i) polling a cached asset according to a first schedule to determine if the cached asset has been active within a first predefined period of time; (ii) if the cached asset has not been active for at least the first predetermined period of time, demoting (e.g., giving the asset a status so that the asset is polled less frequently or not at all) the cached asset to less-active status and polling the cached asset according to a second schedule to determine if the cached asset has been active within a second predefined period of time; and (iii) if the cached asset has not been active for at least the second predefined period of time, demoting the cached file to an inactive status. According to one aspect of the present invention, a cached asset that has been demoted to inactive status can be removed from the cache. In one embodiment of the present invention, if the cached asset has been active within the second predefined period of time, the cached asset can again be polled according to the first frequency (e.g., can be promoted to active status). The frequency with which the cached asset can be polled according to the first and second schedule can be a matter of optimization. Polling according to the first schedule can occur at a greater frequency than polling according to the second schedule. Thus, more active files can be polled more often than less active files.
Embodiments of the present invention provide a technical advantage over previously developed cache management systems by providing the ability to manage a cache without detailed contextual information about the cached assets. Thus, the present invention can be implemented to more efficiently manage a cache containing a large variety of asset types.
Embodiments of the present invention provide another advantage by being able to manage a cache without being subsumed by another software program. Thus, the present invention can be used to manage a cache of assets that are accessed by multiple software applications.
Yet another advantage provided by embodiments of the present invention is the ability to poll active assets more frequently than less active assets, thereby saving significant system resources and improving performance. This can also reduce latency between changes to an asset at the cache and updates to a corresponding asset on another system (e.g., a database).